Packet handling in a mobile IP architecture

ABSTRACT

A method of handling IP packets transmitted from a correspondent node to a mobile node via an intermediate node using the IPsec security protocol. The method comprises, at the correspondent node, identifying specified selector information within the part of the packet to be encrypted, and incorporating the identified information or a digest thereof into a header part of the packet which is to be sent unencrypted, transmitting the packet from the correspondent node to said intermediate node, and, at the intermediate node, receiving the transmitted packet and identifying a policy to be applied to the packet using said information or digest contained in the packet, and applying the policy to the packet.

TECHNICAL FIELD

The present invention relates to packet handling in a Mobile IParchitecture. The invention is applicable in particular, though notnecessarily, to the routing of packets between Home Agents and MobileNodes, where the Mobile Nodes have multi-access capabilities.

BACKGROUND

In order to provide a stable IP connection for user terminals movingwithin and between (access) networks, the Internet Engineering TaskForce (IETF) has specified a protocol known as Mobile IP. Mobile IP forIPv6 is specified in RFC 3775—“Mobility Support in IPv6”. According toMobile IPv6, the current location of a user terminal or Mobile Node (MN)within the global network is stored in a node called Home Agent (HA).The HA dynamically updates the current location of the MN as it moves,in order to make the MN reachable for other nodes trying to connect toit. These other nodes are referred as Correspondent Nodes (CN). MobileIP for IPv4 is specified in RFC 3344.

A MN is allocated a stable IP address, which is referred as a HomeAddress (HoA). When the MN is away from its home network (i.e. thenetwork which assigned the HoA), the HA receives traffic on the behalfof the MN and then tunnels it towards the MN, i.e. communicationsbetween the MN and the CN are sent via the HA. The current location ofthe MN is indicated by a care-of address (CoA), and thus when the HAneeds to forward a packet to the MN's current location, the HA must mapthe HoA to CoA. The mapping between HoA and CoA is called a “binding”.

Mobile IPv6 defines a mechanism referred to as “route optimization”which can be used to optimise the route taken by traffic between the MNand the CN, removing the HA from the route. However, route optimizationis not a mandatory part of the protocol and it may not always beavailable for various reasons. For example, some Network AddressTranslation (NAT) servers may cause problems for route optimizationeffectively rendering its use impossible.

Recent developments in mobile communication have introduced a need tosupport multi-access capabilities for MNs. Consider for example a MNwhich is simultaneously reachable at two different CoA. One of the CoAsmay be associated, for example, with a 3G access network whilst theother may be associated with a WLAN access network. The “monami6” IETFworking group is currently working on the provision of multi-accesssupport in Mobile IPv6.

MNs equipped with more than one (access) communication interface requirea mechanism that controls the usage of the interfaces for communication,i.e. to direct flows to particular interfaces. Such a mechanism willapply a defined policy or policies according to selectors associatedwith communication flows. A typical selector set for a given flow mayinclude the source and destination addresses for packets of the flow. Inthe case of Mobile IPv6, this control mechanism will be implementedwithin the HA that is responsible for data forwarding to a MN. When datadestined to the MN's HoA arrives to the HA, the HA decides to whichinterface (of the MN) the data should be forwarded.

IPsec (IETF RFC 2401—“Security Architecture for the Internet protectedtraffic”) is an Internet protocol intended to provide encryption andauthentication for IP data flows. It can be expected that IPsec will beused to secure end-to-end data flows between MNs and CNs in cases whereroute optimization is not employed, i.e. data flows pass through a HA.The selectors used to select a policy to apply to a data flow willtypically be located within the inner IP header of an IPsec packet. AsIPsec may encrypt this inner header, the selectors will not be availableto the HA and therefore the home agent will not be able to selectspecific policy suited to the selectors and must apply some defaultpolicy. In the case of a MN having multi-access capabilities, this meansthat IPsec protected flows must be routed via a default communicationinterface which may not be optimal.

A similar situation may arise at other nodes within the transport pathand which are required to apply a selector-dependent policy [see IETFRFC 4140—“Hierarchical Mobile IPv6 Mobility Management (HMIPv6)]”.Policies may not be related to selection of an appropriate communicationinterface, but may relate to, for example, a Quality of Service (QoS) tobe applied or a decision on transmitting over multiple interfaces, e.g.bi-casting (or more generally n-casting).

SUMMARY

It is an object of the present invention to provide a means whereby anintermediate node, for example a Home Agent, can apply policies topackets which are dependent upon data within the packets normallysecured by IPsec.

According to a first aspect of the present invention there is provided amethod of handling IP packets transmitted from a correspondent node to amobile node via an intermediate node using the IPsec security protocol,the method comprising:

-   -   at the correspondent node, identifying specified selector        information within the part of the packet to be encrypted, and        incorporating the identified information or a digest thereof        into a header part of the packet which is to be sent        unencrypted;    -   transmitting the packet from the correspondent node to said        intermediate node; and    -   at the intermediate node, receiving the transmitted packet and        identifying a policy to be applied to the packet using said        information or digest contained in the packet, and applying the        policy to the packet.

Embodiments of the invention allow certain normally encrypted data to beprovided in the clear to the intermediate node. An assumption that ismade is that providing this information in the clear is not a securityrisk, or represents only an acceptable risk.

An preferred method for generating a digest of the selector informationis to apply a hash function to the information, the resulting hash valuebeing incorporated into said header part.

In the case where said IP packets are IPv6 packets, said header part maybe an extension header of the IPv6 packet. More preferably, saidextension header is one of a destination options header and a hop-by-hopextension header. Alternatively, said header part is an IPv6 flow labelwithin the outer IPv6 header. In the case where said IP packets are IPv4packets, said header part may be one of an IPv4 header option or a UDPheader.

The invention is applicable in particular to the case where said packetsare constructed and handled according to the Mobile IPv6 protocol, andsaid intermediate node is a Home Agent. Considering the case where saidmobile node is a multi-access capable mobile node, said policyidentifies the access network and/or technology over which the packet isto be forwarded. In this case, the identified information may compriseone or more of the original source address, destination address, sourceport number, and destination port number of the original packet, whichallows the Home Agent to select the interface, i.e. care-of-address,over which the packet is to be forwarded.

It will be appreciated that where the Home Agent fails to recognise oridentify a policy associated with said information or digest thereof, adefault policy can applied to the packet by the Home Agent. In thiscase, upon receipt of the packet by the Mobile Node, the mobile node maysend a binding update to the Home Agent identifying the policy to beapplied to future packets containing the same information or digest.

According to a second aspect of the present invention there is provideda user terminal arranged in use to send IP packets to a mobile node viaan intermediate node applying policies to packets on behalf of themobile node, the user terminal comprising:

-   -   a processor for identifying selector information within an IP        packet and for incorporating that information or a digest        thereof into a header part of the packet, and for employing the        IPsec security policy to encrypt at least a part of the packet        excluding said header part; and    -   a transmitter arranged in use to send the part encrypted packet        to said intermediate node.

According to a third aspect of the present invention there is provided anode for use within an IP communication network, the node comprising:

-   -   a receiver for receiving an IP packet from a correspondent node,        the packet being secured using the IPsec security protocol; and    -   a processor for identifying selector information contained        within an unencrypted header part of the received packet, and        for identifying a policy to be applied to the packet using the        selector information, and for applying the policy to the packet.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically a communications system employingMobile IPv6;

FIG. 2 illustrates schematically the structure of an IPv6 IPsec securedpacket incorporating a hash option within the Destination Options field;

FIG. 3 shows the structure of a destination options extension header ofan IPv6 packet;

FIG. 4 shows the structure of an option data field of the extensionheader of FIG. 3 and containing a hash value;

FIG. 5 illustrates a Binding Update message containing a policy codefield;

FIG. 6 illustrates schematically a signalling flow of Mobile IPv6packets within the system of FIG. 1;

FIG. 7 shows the structure of a UDP packet according to IPv4;

FIG. 8 illustrates schematically the structure of an IPv4 IPsec securedpacket incorporating a Hash UDP header;

FIG. 9 shows the structure of an IPv4 packet containing multiple UDPheaders; and

FIG. 10 illustrates schematically a communications system employingMobile IPv6 and comprising a Policy Enforcement Point.

DETAILED DESCRIPTION

FIG. 1 illustrates schematically a communications system for enablingcommunication between a pair of user terminals, a first of which isidentified as a Mobile Node (MN) 1 and a second of which is referred toas a Correspondent Node (CN) 2. The MN 1 subscribes to a home network 3which facilitates roaming by its subscribers using a Home Agent (HA) 4.As has already been described, the HA allocates a stable IPv6 address tothe MN, and the MN uses Binding Updates (BUs) to keep the HA informed ofits current care-of-address (CoA). In the scenario shown in FIG. 1, theMN 1 has roamed into a location where two different access networks 5,6(or technologies, e.g. WLAN and Ethernet)) are simultaneously available.The exact nature of these networks is not of importance to thisdiscussion. What is of importance is that each access network ortechnology allocates to the MN a care-of-address. The MN informs the HAof the two care-of-addresses using a single BU message. It will beappreciated that the CN may also be a roaming MN employing Mobile IP,although this is not illustrated in the Figure.

It is assumed that the MN and the CN secure their communications usingIPsec. As such, the inner IP headers of IP packets will be encrypted.For all packets to be sent from the CN to the MN, prior to performingthe encryption step, the CN applies a hash function to the protocolheader fields that form the selectors (for example the source IPaddress, destination IP, source port, destination port, protocol versionnumber) for the routing policies within the HA, to generate a hashvalue. The hash function might be SHA-1, or any other suitable function.The hash value can have any appropriate length. The calculated hashvalue is then inserted into one of the “extension” headers which mayfollow the outer IPv6 header.

A preferred extension header for carrying the hash value is an IPv6destination options header. This is illustrated schematically in FIG. 2.It must be noted that these headers are not part of the encryptedsection of the packet. Expected behaviour according to IPv6 is that thedestination headers are only looked at by the destination node for thepacket (i.e. the MN in this case). Use of a destination header to carrythe hash value is therefore contrary to expected behaviour. Analternative candidate location for the hash value is the “hop-by-hop”extension header. However, as the hop-by-hop header is processed byevery node in the path, this leads to performance deterioration and istherefore not an optimal choice. Yet another candidate location for thehash value is the IPv6 “flow label” within the outer IPv6 header (n.b.the flow label is not contained within an extension header). However,the flow label is not well defined, and some applications may use it fortheir own purposes which means that overwriting of an existing IPv6 flowlabel can occur.

Considering further the use of a destination options extension header,the existing IPv6 protocol makes it possible to define a new type ofoption within the destination options extension header such that optionsof this type will be ignored by nodes that do not recognise it. Thisensures compatibility within networks (or network nodes) that do notsupport the new option type.

Each option within the destination options header uses type-length-value(TLV) encoding where each options is defined as illustrated in FIG. 3.The Option Type for the new hash option is defined in such a way thatthe highest-order two bits (bits 16 and 17) are not set. Thus, accordingto IETF RFC2460, if the HA does not recognize the option, the setting ofthese highest order bits will cause the HA to skip over this option andcontinue processing the header. This disclosure does not define theexact option type value. The “Option Length” field is set to the lengthof the hash value in octets. The actual hash value is stored in theOption Data field using the format shown in FIG. 4. Appropriate“padding” may be added at the end of the hash option field.

When the HA receives a packet whose destination is the HoA, it can readthe hash value from the destination options extension header as this isnot encrypted. The HA maintains a mapping between expected hash valuesand policies. The extracted hash value is used to obtain the appropriatepolicy from the mapping. This policy defines which of the (two orpossibly more) registered care-of-addresses should be used as theforwarding address for the packet. The HA adds a further IPv6 header tothe front of the packet containing as the destination address theappropriate care-of-address.

In the event that there is no policy matching the received hash value,the HA can use any of the MN's current bindings for a given HoA (the MNcan have more than one HoA, i.e. the node is multi-homed). If the MNreceives a packet from the HA via a wrong or inappropriate interface,the MN will determine that the HA does not have the proper policyinformation. The MN can then update the HA mapping database by sendingto the HA a BU message containing the hash value. The binding updatecontains an appropriate policy code within a policy field of the BU toindicate the purpose of the hash value. This is illustrated in FIG. 5.The HA returns a Binding Acknowledgement (BA) to the MN.

In order to allow the BU message to contain the update information, thismessage is extended by defining a new mobility option (“hash” option).The general format of the mobility options is defined in Section 6.2.1of IETF RFC 2460. New option type can be added without introducingcompatibility issues as the RFC states: “When processing a MobilityHeader containing an option for which the Option Type value is notrecognized by the receiver, the receiver must quietly ignore and skipover the option, correctly handling any remaining options in themessage”. The exact value of the new ‘Option Type’ field is left openhere.

Within the hash option, the ‘Option Length’ field must be set to thelength of the hash whereas ‘Option Data’ field contains the hash value.The original BU format includes the care-of address, and thus includingthis new mobility option carrying the hash value for that specificcare-of address implicitly creates a mapping (i.e. a policy) which willbe understood by the HA.

When including the hash option in a BU message, the MN should set theAcknowledge (A) bit to on. If the HA recognises the hash option, it mustinclude the received hash option in the BA message which is returned tothe MN as a result of the setting of the A bit. This will ensure thatthe MN receives confirmation both that the HA received the message andthat the HA supports the hash functionality. If the MN receives a BAwithout the hash option included, it should interpret this as a signthat the HA did not recognise the hash option. In this case the MNshould stop including the hash option in further BUs sent to the HA.

If the node required to make a policy decision is other than the HA, theHA is required to provide the received mapping information to the node.FIG. 10 illustrates as an example the case where the policy decision ismade at a Policy Enforcement Point (PEP) 7. Policies are provided to thePEP by the Home Agent 4, which continues to receive BU messages from theMN. Details of such a protocol are, however, beyond the scope of thisdiscussion.

FIG. 6 illustrates the message flow within a Mobile IPv6 architecturemaking use of hash values as described above, where the HA determineswhether the hash labelling functionality is enabled or disabled beforeprocessing a hash option. It will be appreciated that, where interfaceselection is based upon only the source and destination address of apacket and these are contained within the plain text outer header of thepacket, there is no need to enable the hash labelling functionality atthe HA. It is only when the selector contains otherwise encrypted datathat the functionality is enabled. To this end, the HA maintains foreach MN a list of CNs for which the functionality is enabled (i.e. wherethe default is that the functionality is disabled) or a list of CNs forwhich the functionality is disabled (i.e. where the default is that thefunctionality is enabled). A MN can add a CN to this list (enabled ordisabled) by sending a BU message to the HA, containing in the hashoption field the IP address of the CN to which the action applies (nb.the address is not hashed). In the case where the action is to enablethe functionality, the BU message will contain a further hash optionfield containing the hash value which is mapped to a givencare-of-address.

Turning now to IPv4, this protocol does not define the destinationoptions extension header and their usage is therefore limited to IPv6only. However, IPv4 headers may contain options, and a new option typecan be defined to carry a hash value (see RFC 1122—“Requirements forInternet Hosts—Communication Layers”). IPv4 states that “The IP andtransport layer MUST each interpret those IP options that theyunderstand and silently ignore the others”. Unfortunately, IPv4 optionhandling is sometimes problematic, and therefore usage of IPv4 optionsis not recommended.

As an alternative to the use of IPv4 options, the hash value may becarried by a UDP header (called here “Hash UDP”) of the IP packet. UDPpackets have the format shown in FIG. 7, where the overall IP packetstructure including a UDP header is illustrated in FIG. 8. The Datafield within the UDP header can be used to carry a variable length hashvalue. The Source Port and Destination Port values should be set to someknown value(s) which, however, are not defined here. If the original IPpacket already contains a UDP header, the new UDP header is insertedafter the original UDP header (this order is critical), in which casethe packet has the structure shown in FIG. 9.

When the HA receives an IPv4 packet sent to the MN's HoA, the HA caninspect the packet and search for the Hash UDP header. If this header isfound, the hash value is extracted and the Hash UDP header is removedfrom the packet before forwarding it to the MN.

It will be appreciated that, if the HA does not support the requiredfunctionality, it will not remove the added UDP header (Hash UDP) fromthe packet. This is not a problem in the case when the MN supports thehash labelling as the MN can just remove the Hash UDP header. However,if neither the HA nor the MN support UDP based hash labelling, thepacket will be dropped and the associated data lost. It is desirabletherefore to disable hash labelling at the CN by default, and to turnthis on only following receipt at the CN of a specific signal from theMN. Such a signal could be included in a BU message. In contrast,however, that if IPv4 options are used to carry the hash label, the hashlabelling may be turned on by default.

In the use case described above, the hash value included in the IPpacket is used to select an interface over which the packet is to bedelivered. However, a hash value can be used for many other purposes aswell. Examples of such usage are to select a quality of service and/ortransmission control (n-casting). Purpose can be indicted in the“purpose” field of the BU message (see FIG. 5).

It will be appreciated that the use of a hash function is only one meanswhereby selector information can be revealed to the HA despite the useof IPsec. Other mechanisms are possible. For example, an appropriatelabel may be constructed by concatenating the source and the destinationports of the original packet. The use of the hash-based mechanism doesof course have the advantage that it does not cause potentiallyconfidential information to be leaked.

Assuming that the precise mechanism used to generate the selectorinformation is pre-defined (e.g. the hash-based mechanism), negotiationof the mechanism between the MN and the CN is not required, and themechanism can be turned on by default. However, in some environments, itmight be desirable to not to have the hash labelling turned on bydefault. For this purpose the MN may send a signal to the CN to enablethe use of the pre-agreed or selected mechanism. This signal can beincorporated into the next packet sent to the CN. Again, the signal canbe included as an option within the destination options extension headerin IPv6 or as an Option in IPv4.

It will be appreciated by the person of skill in the art that variousmodifications may be made to the above described embodiments withoutdeparting from the scope of the present invention.

The invention claimed is:
 1. A method of handling Internet Protocol (IP)packets transmitted from a correspondent node to a mobile node via ahome agent of the mobile node using Mobile IP and IPsec securityprotocols, the method comprising: at the correspondent node, identifyingselector information within a part of an IP packet to be encrypted, andincorporating the selector information or a digest thereof into a headerpart of the IP packet which is to be sent unencrypted; transmitting theIP packet from the correspondent node to the home agent; and at the homeagent, receiving the IP packet and identifying a policy to be applied tothe IP packet using the selector information or the digest contained inthe IP packet, and applying the policy to the IP packet.
 2. The methodof claim 1, wherein the correspondent node generates the digest of theselector information using a hash function applied to the selectorinformation, and incorporates a resulting hash value into the headerpart.
 3. The method of claim 1, wherein the IP packets are one of IPv6packets and IPv4 packets.
 4. The method of claim 3, wherein the IPpackets are IPv6 packets and the header part is an extension header ofthe IPv6 packet.
 5. The method of claim 4, wherein the extension headeris one of a destination options header and a hop-by-hop extensionheader.
 6. The method of claim 4, wherein the header part is an IPv6flow label within an outer IPv6 header.
 7. The method of claim 3,wherein the IP packets are IPv4 packets and the header part is one of anIPv4 header option or a User Datagram Protocol (UDP) header.
 8. Themethod of claim 1, wherein the selector information comprises one ormore of an original source address, destination address, source portnumber, and destination port number of the IP packet.
 9. The method ofclaim 1, wherein the home agent removes the header part prior toforwarding the IP packet to the mobile node.
 10. The method of claim 1,wherein the mobile node is a multi-access capable mobile node, and thepolicy identifies the access network and/or technology over which the IPpacket is to be forwarded.
 11. The method of claim 10, wherein thepolicy specifies a care-of-address for the mobile node.
 12. The methodof any claim 1, wherein, if the home agent fails to identify a policyassociated with the selector information or the digest thereof, adefault policy is applied to the IP packet.
 13. The method of claim 12,comprising, upon receipt at the mobile node of the IP packet to which adefault policy has been applied, causing a binding update to be sent tothe home agent identifying the policy to be applied to future packetscontaining the the selector information or the digest.
 14. The method ofclaim 1, comprising, for each mobile node, maintaining at the home agenta list of correspondent nodes for which the steps of identifying thepolicy and applying the policy are to be applied or are not to beapplied, the method further comprising sending, from the mobile node tothe home agent or to a node responsible for inserting policies into thehome agent, a binding update message containing an IP address of acorrespondent node for which the policies are to be identified or arenot to be identified and, in a case where the policy is to beidentified, the binding update message also containing the digest andidentifying a corresponding policy.
 15. A user terminal for sendingInternet Protocol (IP) packets to a mobile node via a home agentapplying policies to the IP packets on behalf of the mobile node, theuser terminal comprising: a processor for identifying selectorinformation within an IP packet and for incorporating the selectorinformation or a digest thereof into an unencrypted header part of theIP packet, and for employing an IPsec security policy to encrypt atleast a part of the IP packet excluding the header part; and atransmitter for sending a part encrypted IP packet to the home agent.16. The terminal of claim 15, the processor generating the digest of theselector information using a hash function applied to the selectorinformation, and to incorporate a resulting hash value into the headerpart.
 17. The terminal of claim 16, the processor incorporating theresulting hash value into a destination options header of the IP packet,where the IP packet is an IPv6 packet.
 18. A Mobile Internet Protocol(IP) compliant home agent for use within an IP communication network,the home agent comprising: a receiver for receiving an IP packet from acorrespondent node, the IP packet being secured using an IPsec securityprotocol; and a processor for identifying selector information containedwithin an unencrypted header part of the IP packet, and for identifyinga policy to be applied to the IP packet using the selector information,and for applying the policy to the IP packet.
 19. The home agent ofclaim 18, the node being a Policy Enforcement Point.
 20. The home agentof claim 18, wherein the processor identifies selector informationcontained within a destination options field of the IP packet.